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REMARKS 

Applicant has amended the claims, and submits that the amended claims 
overcome all objections and rejections, for the reasons given below. 

With respect to the claim objections stated in Paragraph 3 of the 
Official Action, Applicant has amended the claims to insert the indefinite 
article into the preamble of each claim. Applicant believes that the 
objections are thereby overcome. 

Applicant has amended the claims to overcome the rejections under 
Section 112. In particular, Claims 1 and 4 have been amended to recite 
that the "transmitted messages" are messages transmitted between the 
server and the client. Claims 1 and 4 have been amended to recite that it 
is the representative of the authority that is inserted into the network. 

With respect to the translation of transmitted messages, the 
"translation" refers to possible modification of messages, as further 
explained in the dependent claims, mainly Claims 2 and 3. In these claims, 
the modification of messages is a change in protocol. The change could 
also be a change in the public key. In other words, the contemplated 
change may modify the information relating to security, included in the 
messages, as required to implement the authority's message exchange rules. 

Applicant submits that the claims, as amended, fulfill the 
requirements of Section 112. 



The Examiner has rejected the claims under Section 101 as non- 
statutory. Applicant submits that the claims, as amended, define statutory 
subject matter. 

In particular. Claim 4, relating to an apparatus, is defined to 
comprise tangible components, namely a server, a client, and a means for 
securing messages exchanged between the server and the client. Applicant 
submits that the recited combination identifies tangible elements, and that 
it therefore comprises statutory subject matter. 

Method Claim 1 has also been amended to make it relate more clearly to 
a tangible embodiment. Similar to what is recited in apparatus Claim 4, 
the method is performed with a server and a client, linked by a data 
transmission network, and having an authority which defines message 
exchange rules in the network. Applicant submits that these features are 
sufficiently tangible to define statutory subject matter under Section 101. 

Claim 1 has also been amended to recite the positive steps of the 
method, so as to define the method more precisely. Thus, for example, the 
method includes the steps of providing control in a decentralized manner by 
the representative of the authority, and setting up communication between 
the server and the client only through the representative of the authority. 
Applicant submits that Claim 1 defines a proper method, in fulfillment of 
the requirements of Section 101. 

Applicant submits that the rejection under Section 101 is therefore 
overcome . 
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All of the claims have been rejected under Section 102, over Urien 
(US 2002/0138549). Applicant submits that the claims, as amended, define 
patentably over Urien for the following reasons. 

1. Urien fails to show a client which is a smart card or a 
mobile communication system 

Claims 1 and 4 recite that the small client is a smart card or a 
mobile communication system. In Urien, the client is not a smart card or a 
mobile communication system. Instead, in Urien, the client is a terminal 
1, which is associated with a smart card 2a. 

The fact that Urien does not show a client comprising a smart card is 
apparent from the following teachings of the reference: 

The terminal 1 of Urien has "the other hardware or software elements 
common to the prior art" (paragraph [0068]). The terminal 1 includes a 
card reader 3 (paragraph [0073]). As in the prior art, the terminal 1 may 
be an individual computer, with circuits 11 for access to the Internet 
(paragraph [0022]). The terminal 1 includes a CPU, random access and read 
only memories, magnetic disk mass memory, a disk drive and CD-ROM drive, 
etc. (paragraph [0023]). 

The terminal 1 communicates with the remote server through the 
Internet with a TCP/IP protocol. In paragraph [0036], Urien states that a 
TCP/IP protocol is not presently implemented in available smart cards. 
Thus, smart cards cannot receive and transmit data packets by such a 
protocol . 
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2. Urien fails to show a representative of an authority inserted 
permanent 1 y between the client and the server 

The Examiner holds that Urien shows a smart card inserted between a 
client and a server. This holding is incorrect for the following reasons. 

In paragraph [0043] of Urien, the wording "reroute all or part of the 
data stream" does not mean that the smart card (the representative of the 
authority) is inserted between the client 1 and the server. It means only 
that the client 1 may decide to forward to the smart card the messages 
received from the server, and may decide to send to the server messages 
received from the smart card. In all of the embodiments of Urien, the data 
stream goes through the client (see Figures 6, 7, and 8). 

As described in paragraph [0157], Urien shows a smart proxy that 
filters or processes the data originating from the Internet. But, once 
again, the data are first received by the client 1, and this does not mean 
that the smart card (the representative of the authority) is inserted 
permanently between the server and the client. 

Paragraph [0153] of Urien shows a filter function, but this passage 
does not mean that the representative of the authority is inserted 
permanently between the server and the client. 

In paragraphs [0216] -[0218] of Urien, the data stream is decrypted and 
verified by the filter of the smart proxy. But this does not mean that the 
smart card (the representative of the authority) is inserted permanently 
between the server and the client. 
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3. Urien fails to disclose a system in which communication is set up 
between the client and the server only via the representative of 
the authority 

Claims 1 and 4 have been amended to recite that communication is set 
up between the client and the server only via the representative of the 
authority. Support for the latter wording is provided at page 7, lines 20- 
22 of the specification. This feature insures that the necessary 
verifications are effected (page 7, lines 22-23). 

Urien fails to disclose or suggest this feature, as is apparent from 
the following sections of the document: 

a) Paragraph [0170] states that "the filter function 28 does not 
perform any processing on these data"; 

b) Paragraph [0226] states that the "opaque stream can be 
processed solely by the agents located in the terminal 1"; 

c) Paragraph [0241] states that "the data originating in the 
remote server 4 ... no longer pass through the smart card 2a"; 

d) Paragraph [0244] states that "[o]nce a phase of negotiation 
has been completed ... since the data are directed from the Internet RI to 
the terminal 1 in the clear"; 

e) Paragraph [0248] states that "the opaque data stream is 
processed by the set Ty^2'^3 and accordingly does not pass via the smart 
card 2a"; and 

f) Paragraph [0252] states that "[i]n all cases, only a low- 
volume, low- speed data stream, comprising what are called the critical 
data, pass through the smart card 2a". 

The above -cited paragraphs show also that the smart card of Urien is 
not inserted permanent! y between the server and the client, as is now 
recited in both of the independent claims. 
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In summary, Urien does not teach or suggest the features now recited 
in independent Claims 1 and 4. These claims are therefore believed to 
define patentably over Urien. The remaining claims are dependent, and are 
therefore also believed allowable. 

For the reasons given above, Applicant submits that the application, 
as amended, is in condition for allowance. Applicant requests 
reconsideration by the Examiner, and early favorable action. 
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